1.5.1. Issues and findings

It was determined there is no real good reason for a server to remember a URL specified by a client. Implementers want to be able to forget a URI but do want to be able to send back the real URI of the meeting that is the final object. There was discussion that there may have been something in the CAP draft that handles this. That may be a resource for text to add to CALDAV.

When a client does a PUT the server sends back what the URI is at the end of the process. There is dialog out on the CALDAV list that may point to possible resolutions.

If an underlying WEBDAV server does not support ACL or locking, then the client must handle everything. Locking would then be handled by tags and “if match” — you have to do a put operation that fails — a lock will guarantee you have a connection if you don’t get data back down the pipe.

It was determined it is hard to lock a collection. The question is will this cause a performance hit on the server?

In order to determine if locking is required, we need good usecases or test scenarios to prove or justify requiring locking. It was suggested that implementers use eTags as a workaround. However, server implementations will need to handle limits on locks. This gives rise to the question of how to handle things when the lock is broken and the eTag has changed. Consensus among the group was to not make it mandatory.

One question that came up pertained to HREFs. The question is “are HREF’s allowed to be relative in Webdav?”

The majority of issues found during testing were not with the CALDAV specifications, but more with RFC2445 interpretations. For example, section 4.6.5 of RFC2445 addresses vtimezones and rrules. The first paragraph in this section seems to be interpreted differently by various clients. We will need to post this issue to the Calsify mailing list in the hopes that group can add this to their list of required changes/enhancements to RFC2445.

It was discussed that there might be an issue with propstat in the Caldav draft. Bernard from Oracle is not sure and will research this.

The following page shows the cases tested. The names of the clients are not noted — we use a code instead. C1, C2 and C3 are clients and S1 and S2 are servers.